前一陣子Yahoo舉辦了YUI Conference2009，請來了兩位大師級人物：Brendan Eich做開場演講，Douglas Crockford做閉幕（？我不太確定，應該是閉幕）演講。YUI Theater網站上面有他們演講的錄影及投影片：

Brendan Eich:
* http://developer.yahoo.com/yui/theater/video.php?v=eich-yuiconf2009-harmony （新聞及低畫質影片都先在YUI Blog上發布）
* http://www.yuiblog.com/blog/2009/11/03/video-eich-harmony/ （有高畫質版的影片及演講紀錄，建議看這裡的）

Douglas Crockford:
* http://developer.yahoo.com/yui/theater/video.php?v=crockford-yuiconf2009-state （新聞、低畫質影片及投影片都先在YUI Blog上發布）
* http://www.yuiblog.com/blog/2009/11/04/video-crockford-state/ （有高畫質版的影片及演講紀錄、投影片，建議看這裡的）
從這兩篇演講談起
接下來，就從這兩篇演講談起。

這兩位Javascript的重要人物，都做了一些回顧，裡面有幾個重點：

其一：雖然使用Javascript的人很多，但是直到2005年AJAX技術出現之前，它很缺乏殺手級應用，所以沒什麼人重視，真正理解這個程式語言的人也很少。（我也完全不理解）

其二：制定ECMA-262標準的TC39委員會，積極活動的成員其實很少，到Crockford參加時大概只有Yahoo, Adobe, Mozilla, Microsoft, Opera幾家公司的代表，更大的問題是，這些代表裡面幾乎沒有人真正在使用這個語言。等到TC39開始積極制定ECMA4時，當時的ECMA4與使用者其實有些脫節，更嚴重的問題是，這個標準沒有解決ECMA3的重要問題：「安全性」，只是制定出許多與舊規格不太相容的新功能...

Crockford想要改變這個方向，雖然大家都說不可能，不過他還是找到一個幫手：「微軟」，因為微軟也對用戶相關問題憂心重重。有了幫手之後，TC39委員會內部就決裂，分成ECMA4與ECMA3.1這兩派。後來ECMA主席出來調停，要求統一口徑，最後的結果就是ECMA5，而原本ECMA4規格的東西就推遲到未來。

我把這個過程講得很簡單，不過當時的過程應該是針鋒相對，所以Brendan Eich形容Crockford是Gandolf，在橋上面對ES4Rog說："You shall not pass." ...Crockford則形容當時針鋒相對的情況，就好像一部電影：「Twelve Angry Men」，十二個陪審團團員擠在窄小的陪審室中針鋒相對。（看過這個演講才明白，這個標準的幕後黑手其實是Crockford）

現在原本的ECMA3.1變成了ECMA5，而且進入公開review的過程，但是還是有一些危機，這個危機來自IBM...來龍去脈是這樣：如果用過Javascript做計算，可能就會碰到數字不精確的問題，這個問題來自ECMA3中，規定數字是要符合IEEE754標準。IEEE754用二進未來表示十進位小數的方法，但是因為它是用二進位來表示，結果在一些狀況下數字會出現不精確，例如0.1+0.2...

IBM制定了一個IEEE754標準的延伸，叫做IEEE754r，他參與TC39委員會只為了一件事，就是要把這個標準綁到ECMA-262中。問題是這個標準中使用的演算法，會使數字計算的的速度慢上數十倍甚至百倍（詳情請參考Crockford的演講），所以ECMA5沒有把他納入，結果IBM就威脅，如果不納入，他就投反對票...看起來這個是標準通過的最後威脅了。Crockford也在演講中針對IBM的要求做了一些呼籲。

新規格的重要性
雖然很多人的焦點可能會放在JSON，不過我覺得真正重大的改變在於安全性。

熟悉Javascript的人應該都知道，這個語言有驚人的動態與彈性，透過 "." 與 "="，幾乎就可以修改任何東西。原生的Javascript物件properties可以有ReadOnly、DontEnum、DontDelete等屬性，但是自訂的物件沒有。這在網站服務混搭成為主流趨勢的現在，就變成了安全的大問題。你寫好的Javascript物件，隨時可能被從第三方網站「混搭」進來的程式不小心甚至惡意改動。為了解決這個問題，Crockford曾經寫過一個東西叫做ADSafe：http://adsafe.org/，嘗試用Javascript做出一個Javascript直譯器，讓第三方的Javascript只能在這個直譯器的沙箱環境中執行。能做出這個方法很厲害，但是好像沒什麼人真正拿來使用。除了效能問題，我想功能上的限制也會讓人裹足不前。

所以最徹底的解決方案，還是從標準規格下手。ECMA5裡面有一個東西叫做Strict Mode，把他打開後所有嚴格（但是可能會讓程式不相容）的安全功能就會啟動。Crockford在演講中也強烈建議使用它，如果在strict mode中無法執行的程式，在未來的標準中就可能完全無法再執行。至於新規格在安全上最重要的東西，我想就是對於物件Properties的權限控制。除了在產生物件時可以控制屬性的讀寫、可擴充等權限，也可以透過freeze, seal等方法把物件加上存取限制，而在properties存取上，也可以透過accessor函數來進行，所以可以有彈性地透過這些函數來對存取加以控制。（有興趣的話，我在前文「Javascript面面觀：核心篇《ECMA-262 Edition 5》（上）」有做過一些介紹，也可以參考文中John Resig部落格文章的連結，或是直接看一下規格草案的pdf檔案）

其他部份主要都是加強這個語言的易用性、功能及表達能力，或是修正舊規格中一些不合理的地方。

（有興趣可以訂閱：https://mail.mozilla.org/listinfo/es-discuss，這是討論ECMAScript規格的主要maillist，內容很豐富，可以看到許多人建議許多各式各樣的功能跟語法，Brendan Eich常常在這裡出沒。）

展望
其實Crockford在演講後面還提到HTML5，他認為這也是個在畫大餅的規格，不如來個HTML4.2，修改目前規格不合理的地方，並且把DOM規格改得好用一點。（如果好用，就不會有jQuery了）

就算新規格通過了，要等到所有廠商都支援還是要花不少時間，要等到IE6消失可能需要花更多的時間...也許到時候，網頁前端的環境可以變得安全一點吧？另外前端工程師的工作也可以不那麼辛苦了吧？不過幕後的問題來源其實已經做了許多改變，除了推動ECMA5的制定，新版的瀏覽器對標準的支援也更好。另外，從一些地方可以看出他的努力：http://blogs.msdn.com/jscript/archive/2009/06/30/steps-toward-creating-compatible-ecmascript-5-implementations.aspx以及http://es5conform.codeplex.com/。（提示：部落格的作者身份？）

說實話，Javascript是個不好使喚的程式語言，因為不好使喚所以才讓人花時間研究阿，這真是個漫長的歷程...

（我寫這篇的素材，主要還是從Crockford的演講來的。Eich的演講提到很多技術細節的歷史淵源及決策過程（究竟他是Javascript的發明人，自始自終都在關心這個語言的發展），Crockford的演講主要集中在幾個攸關標準通過的重點上。兩個人的演講各有擅場，都值得一聽。）